layout reader ctx#8037
Conversation
Merging this PR will improve performance by 13.42%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ⚡ | Simulation | take_map[(0.1, 1.0)] |
1.9 ms | 1.7 ms | +16.15% |
| ⚡ | Simulation | take_map[(0.1, 0.5)] |
1,092.6 µs | 986.5 µs | +10.75% |
Tip
Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.
Comparing os/layout-overrides (34bf8aa) with develop (5aa3f3d)
| /// children helpers and survive any single stack frame. | ||
| #[derive(Clone, Default)] | ||
| pub struct LayoutReaderContext { | ||
| values: Arc<HashMap<TypeId, Arc<dyn Any + Send + Sync>>>, |
There was a problem hiding this comment.
would that import bug that hit our use of type id be relevant for this type of use as well? I can use the layout id here, I think it is a bit of a weirder api to have but should work
joseph-isaacs
left a comment
joseph-isaacs
left a comment
There was a problem hiding this comment.
Can we use a Array like Id instead of a TypeId
|
What's wrong with TypeId? We use this structure for all ephemeral context objects, i.e. VortexSession. It works correctly, is very fast, and helps keep it clear that this stuff is never serialized. The general |
|
A type id is not a stable id outside on a single compiler patch version. |
Signed-off-by: Onur Satici <onur@spiraldb.com>
Signed-off-by: Onur Satici <onur@spiraldb.com>
onursatici
force-pushed
the
os/layout-overrides
branch
from
906945c to
34bf8aa
Compare
3 participants
Summary
Introduce
LayoutReaderContext, a typed-data registry threaded through reader construction so an ancestor layout can publish values that descendant layouts look up by type at construction time.Breaking: Layout::new_reader and VTable::new_reader gain a &LayoutReaderContext parameter. Out-of-tree impls will get a compile error and must add it